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Introduction 



1.1 Purpose 

In recent studies Ericsson haye been inresrigymg the technical and oomiiieraal 
feasibility of an eady launch of non-conrersation^ IMS sohmons. Wnhia these stodLeSi 
the main guiddine was that the mmKUHiv-eisationd IMS service 
com^enamted by conversational service capabilities in the CS domain. For maz^ service 
T^n^n"^ (that do 6^, not require an y tig h t sy n r hmn isari on between the convcrsaQonal 
and the nofHKmversational miedii^ that ^){iroach tra 

However, the quesdon also aiised wfaafwouldbe the addedrvalueto provide support &r 
CQgversanonal, voice, services as part of the IMS at an eufy stage. 'What are the benefits 
and/ or oppoitamdes? How efBdent ^uld the actual solutions be? XVhat would be the 
impact on later standardisation and product releases? If oot feasible, which parts are still 
missing (e.g^ as prepatanon for K6) 

Erksson need a gcx>d tmderstaiiding of these issues as input to customer cfiscussions, 
product devehyment and standafcfisation. 

Hiis p^>er is therefore an anal}R&5 of some of die tedmical issues to support 'eaify 
conveisatbcal IMS' services in order to hrip consolidate the view on the conesponding 
oppoitiiniues and challenges. 



1.2 Scope 

The paper inaiz4y addresses the technical aspects, fiocussing on the mam issi^ 
effidendy support conversational IMS services on the (radSo) aooess side. The business 
and mote general aspects are outside of the scope of this paper and are to be ad(^^ 
m otheTj ^^^*'*^^*y i stui£es» 

From a service perspective the focus shall be on voice: Most conversational IMS servicxs 
vould at least contain a voice elemenL Also horn a network (Smensbningpen^ectivc^ 
the vdce service would have the biggest in^ct near-term and will therefore to a largp 
extend detemiioe the feasibili^ of axijr *earlj^ conversational IMS' dq»la;ynients. 



1.3 Background 

It has become apparent that it wi&be daDenguig to define the full IMS functionalx^ 
within the scope of 3GI? R5. A key aspea is tlut it is of the faigliest iizi^^ 
ensure a h^h*q>ulit]r standard for IMS^ Sinoe Hrksson stroll^ 
cnacial demertt in fumre miilttnM^ia-enabled ooinninnirarion oeiwoiks, ic is not 
accc^naUe to rush the spedficatiojis at this stage. There is atoo hi^ ziskdiat sn 

ipim^"" graTw<arr< qimilfl imA^rmm^tht^tpe^ntn} and OOfflmerdal OppOltUmtieS IMS 

wiQ provide in the kmg run. 

Based on the assumption that the complete IMS funGdonalicy needs to be disrn'hiiTfd 
over at least one more rdease, there are discussions ongoing bothin (firea customer 
contacts and standarxfisation, how this phasmg shall be done. The main, near-temi, IMS 
market drivers identified within ihese customer comacts are: 

support for presence and instam messaging based services to enhaace the 
existing service pordblio 



• suppoR for IMS based (convetsanooaQ semoes to provide a more flcdble 
ana richer conmmmcatioii ezpoience chat will make it easier (or opencocs 
CO diff erenriaze tbemselves 

- suppoxc for IMS based voice services as an altemathre to CS tdephoxxf 
services to streamline padcet-switcfaed technology based necwoik 
architeccure asdopemxons 

Ericssoa would also like to promote eaify deployment of IMS solutions to aDow the 
industry to get eaiiy experience wkh IMS technology, both from a technology and &am 
an iiser-esperience perspective 

lUs p^>eris darifies some of the tedmkal issues rdated to die feasibility to deploy 
conversaiioflal, voic^ serykes based on the 3GPPR5 yedficadons as a complfment to 
earlier studies into non-conversational services. 



2 Concepts 
2.1 Telephony 

TcScphoiy is of course the ixrdl known service that todsy accounts for an overwhdmmg 
part of the trafiic in mobile nerwodts. Some of the charactetistics of the tdephoi^ 



• An extensive set of standanlised services and featares^ some of wluch are stri^ 
zequiied by the r^Mhsuvs as a prerequi^ for offering the ser^ 

• Faidy high speech qualiQrbodiffltemiis of £ddity and low dciay^ 

• Fairly h^quali^ also mtemcis of response times for conneoios sec upf service 



• Vey high efficiency in terns of radio spectrum iis^p and coverage. 

• area availahOhyjConsiscent service available where^ 

2.2 Multimedia Commiunlcation 

Muiiimecfia in this ''^i^ m r xt is human to human ffHniTHTni^Tffion established via 3GFP 
IMS. Voice can be, but does not have to be, one componeot in this <_ 
Some th<^ rharartiirisrirg nf tnufn'fiiwfKa wfr» oommunicadon are: 

• Voice is only a media coji^nent, among many other. During an estaUished 
mukiniedia session, voice comnsunication is freely established and disoonneaed 
indepcndrniiy from the session itself, just like other media. 

• Very linle standardised services and feamres both when it oomes to session 
establishment and the ly^pAia itsdf. 

• Tq what gytant r^ilatnty rptpiirgmpnte will Up appli^ tf\ m^^h^fp^'t^ nir f\)fv^]ry 

component is undear. It is however dear that the requirements that are put on 
tdephony cannot be 2pp}ied as suck 

2.3 IMS Voice Service 

It would in prindple be possible to use muldmedta capabilities to emulate tdqihony like 
services. Tlus would end}le operamrs to offer a tde(£ony like service using the FS 
domain and the IMS iofrastruaure. There are, however, ammberof aspectsto 



• Specinim efficiency shoidd be ooxnparal^ to the CS domain se^^ 
sigaificant acidxt&oaal vahie can be provided by^ the PS domain tel^hon^ service 

• Legal requirements on the tel^hoi^sernce must be fulfil 
fulfilled by other means 

• llie<iuaIity^aUaspeainch!dingsemceanrai^ 

compsahle to the CS domain service unless k can be offered at alower price or 
together wtth some stgpHicant additional vahie 

• The service level should fluuch die CS domain service Wei ufdessh can be off^ 
a lower price: 

3 Packet Voice Service Scenario 

In this section an IMS voice scirice carried on iJietMTS PS domain is oudined The 
scenario bdow describes a paxttcular profile of die IMS voice service which in this 
document Is called packet voice service: The desci^mon will be used as a base for the 
anal^^ of a realisation and major characteristics of such a service. The description is 
focused on the access necwodc aspects and amplified to the case in -which the caller and 
called are using the same service. 

The Packa Voice service is intended to a large emit replace the CS domam tdic^^ 
characterised by: 

• The padutvoiix service Is the dominamsetvice^heocedri^^ 

• It is assumed that siyport fbrthe tradirional CS domaan tdephony is still offered and 
is used to fulfil legsj requirements^ such as Emergenqr calls, and si^>pait for roaming 
subscribers. 

• The service should be perceived by the end- user to be as good asi Of ooxDparablc^ 
•with the ttarfirional rnohile tdephorrf service in terms of pecfd^^ 

In this scenario^ die main support provided by die network is: 

• transport of the application flows, packets, between temiinals; 

• rouung of the application session oontroi packets. 

As can be seen in figure 1, there are three disdncdjr different application flows to be 

• the medift> speech sanqiks carried the KIP- pTDtood over UDP; 

• media control- RTCP messages over UDP, and 

• application ccmtzx)!- SIP messages carx)ring SDP mfomuttion over UOP. 




jR^we i BtoxFisckBt VoioBApf& u tu M noas 



Tbe overall requixicmenr from the end> user on the pezfDrmance and cost of the packet 
voice service is reflected by requirements on howthe necwozkroQCe and transport each 
of the individual flows. 

Each of the flows aHea the overall service behaviour, pofbtmance. For example^ the 
media flow is significant in when it comes to pr^ndtng a good speech qua&jr and the 
application oonttol flow has a significance when xc comes to e.^, service set-up time: 

In addnion, the requirements of the operator on a reasooable provisioning cost also 
conies into the picture. In diffexmce to over- provisionittg access netwQiks, such as 
LAN's; cdhilar is about providing seamless^ wide- area coverage at a reasonable cosl In 
contrast to over provisioning access technologies, one cannot ^thxow bandwidth* at the 
problem, since this will lead to unreasonable pxovisionii^ costs. 



4 Overall Architecture and realisation 



4.1 Overview of the System Realisation 

When usii^ the WCDMA techndog^ to access the SIP based IP multimc<fia sys^^ 
SIP signalling and the media streams must be transported over the Universal Tenrescrial 
Radio Access Netwo^k(L^IUA^Q and Packet Switdied do Efficient 
resource is enabled with careful choice of the configuration used to transport 
the IMS bearers, mrhiding the SIP stalling and media, over the Air interface. 




SIPAJOPyiP 




RTCnUDP/IP 



PDPcontB3(t 1 Gi to IMS network 
»t« 



^^o92 ExBftifktfhum fsTRsjoBt Von 

The mobile chooses the nieam by which the ai^cation flows IMS bearers should be 
tranqiorted over the PS domain. This is dependant upon the user requirement, 
^^^icatbtt, the ayaifabillTyof raxSo bearers, charing considerations. Figure 3 shows a 
voice communication using the SIP based IP multimedxa system. ThcSIP/SDP 
signalling the AMR (Kl?) media and the RTCP signaSii^ has their own PDP contests 
(and hence Radio access bearers). The POP context for SIP/SDP signalling is alw^ 
active to exiable the mobile to recdve IMS sessions, bm during Icfle periods th^ 
be deactivaxed. 
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The mobile selects the oonfigMiation of the access networic required to suppoits the 
oomaumcadoa media's negotiated through the SIP signalling. \C1ien estabHshIng the 
required configqradon, the mobile provides the required Traffic flovtemplate (TFI) 
inrormaiiott to the GGSN, instnscting tfaeCGSN to pkce the oonea flows in the 
selected PDP contexts. The mobile must hence know how to map the signalling and 
media flow to PDP 



4.2 Assumptions 

llie basic assumptions is that the packet voice service is defined withm the 1^^ 
3GPP Kdease 5 standards indiuEng referenced IETF RFCs. This means e.g, that IP 
header oompiession as wdl as the SIP signaQii^ compression is supported while some 
other opdmisatnns like Unequal Error Protection and Rare Control are not supported. 

To further simplify^ die padset voice service it is assuosed that ofd^ the AMR 12.2 kfcps 

mode is used. 

The packet voice service shall be oonqiliant withSGPP Release 5 SIP signalling including 
ccteoswns for eigi, SIP compression and Securdy. 

It shodd be noted diat 3GFP awi IETF is stiQ working on the reqin^ cxtensfOQS 
and the messages contain variable ieng^£eids, hence the message size can not be 
exactly determined. In the charaaeristics analysis bdow the message sizes hsve escusated 
conservatively. 

It is assumed that the packet vdce media and signaHmg fbws will require 3 separate 
PDP contexts and the associated RABs 

• One PDP context for SIP/SDP 

• one PDP Gomezt for AMR (RTF) 

• one PDP context for R!rCP 

It would have been natural to put the RTGP flow on the same RAB/PDP contest as the 
SIP/SDP flow or the AMR (RTF) flow, btic it does not seem possiUe. Onrnfwnatioa of 
the AMR (fGl) flow and the RTCP flow would resuk in excessive use of tatfio 
resources. Combination of the SIP/SDP flow and the RTCP flowwoi^ conflict the 
diargjbg requirement that the GGSNshaU be aUe to ensure that the FDPcontes 
f or sigaal£ng is only used for s^i^ling to and finoffl the P-CSCF. 

Note that changes in the standards or <^>er3tor requirements may influence the 
^gsmoption s» 

4.3 Overview of the information flows 



SIP/SDP 

SIP/SDP signafling is used for mukimedia session control Some aspects of the service 
behaviour depend on the QoS g^ven to the SIP/SDP signalling, e.g, service STailabiliiy 
and response times. The session establishment time for example is (£recdy proportional 
to the ddays experienced by the SIP/SDP messages. 

SIP signalling is arequest - response type of conununication with typical packets sizes in 
the range 300 - 900 oaets. Sesnon set up involves a rather b^ iiuiii^ 



The number of messages that are exchanged varies, but for a straigMonvard session set 
up there are tyfkaSfy 11 messages 'with a total vohime of nfimimitm 7.3 )^aytt. 

SIP/SDP signalimg oon^iession can be used to reduce the SIP messages and tberebjr 
reduce the transmission dday. SIP/SDP messages are transferred compressed between 
theUE andthe P-CSCF. Compression is thcre^tran^areotto the^ domain and the 
ra&> netwodcsL "^th conqncssion the SIP/SDP message volume can be re^jced 
(nomaaO^ the compression would be apprQxifflatd)r 4 times). However^ the setup time Is 
still influenced by the number of loimdnips. 

IP header conipressionwdl further reduce the amount of ixifbrmadon that needs 
transferred over die airinter&ce. 

Tliere are three QoS aspects of special napottance for the SIP/SDP s^iaUingtnffic, 
when used for the packet Toioe service: 

• Bh rate: Signalling is WyolunxtnlEic with a low demand of average ba^^ 
However in order to ke^ delays down, the transmis^on rates should be higher 

• Deh^: Total dela^ for a message is the impoitam QoSparanuter.lt is par^ 
depradent on the anrailablebit rate but also infliimneH bjr bearer handling ddays and 
retransmissions over the air interface. 

• Priofily ! To gniairg a gnod <gTVi«^ hghawnir alsn tmfi#r Ut^nry IrqH ff?nfe>g^!^ 

signalling traffic should get piioii^. 

Of the avaibhie QoS dassesi die imerutxve dass ts the one that is most suh^ 
type of traffic. 

SIP sgoaOittg should not be put on allA^ bearer that carries large volume user data» 
like aoearerused ferwid) browsingi. the same bearer is used, there is no w^ 

prbxxtise SIP messages orodier agnaHing 

n>etgfofg a dfldtratfid h^armr Aemid h^ ^^KIi'Aatl fnr CTP (amj mtW^tmilflr oyiaHingj 

In tfab wajr the signalEng does not hacve to compete with Other tni^ 

Bm even with a dedicated bearer there m:^ be a need for QoS in^provements fOT 
application signalling when using an intetacdve bearer, andthis is whjr a S^oalfiz^ 
TralBc bearer coremly is discussed within 3GFP. 



RTP flow 

The RIP flow cardes the media fiow, which in tlm case is the 12J2 kfaps 

^>eeck In adc£don to the AMR coded speeds the RlPp^rioad also contains a pa^oad 

descriptor which gives a total psyload of 32 oacts. 

The overall IP packets for die media flow are AMR/BTP/UDP/lPv6, where the total 
header infennadon is 60 octets^ which then g^es a total messa^ size of 92 octets. 

For the RIP flow the proposed solution is non-optimised in the sense that an unequal 
enor protection (UEP) is not indnded. Por the iiudu&on of UEP the destred approach is 
CO use UDP lite which is xiot availahle in a 3GPF release 5 time frame. 

In adcSdon to the speech padset there are also the SID packets (7 octets ps^ioad) and 
DTX. 

For the RTP flow a conversational RAB is the best dioicev and this oonversanonalRAB 
has to be G^aMe of transfendng 92 oaets every 20 ms^ le., a data rate of 36.S kfaps. 
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RTCP flow 

The RTCP flow have messages which are Tisually a bit larger thaa the RTP messages. 
TheKTCP flow messages are also traosferrei nther ixifreqoendy^ To allocate a 
conversadonal RAB for this flow would result in an unnecessary capacity reservation and 
a bener approach seems to be to use an interactive RAB for the RTCP flow. This 
interactive RAB would be allocated ai the same rime as the conversational RAB for the 
BTPfloWiWfaichmeaxuihatthistnteraoiveRAB will betraiisferredona dedicated 
channel, i.&, it will to some extern bene& bnm the performance of a dedicated chanjod. 

4^ Signalling flow overview 

This section cbytar shows one example of a session r^raMishmenr that oofy involves a 
speech conqwxienz. 

It is assumed that both UEl and tJE2 are already ngjscered on the IMS level and that 
th^ also have FDP contexts for signalling Hie RABs have thou^ been rdeased due to 

inactivity. 

Flow outline 

« UEl starts with a re-establishffient of the RAB 

• WhendieRABre-esti^llshmentisflnishedUE 1 can send the INVTTE message 

towards UE2 

• ^ceUE2 does not have the RAB Iot the Signalling FDP OQDtezt active die SC^N 
win page UE2 who win then re-establish the RAB. 

• The U£2 can now receive the INVlTii and will respond with a Progress indlcatiott 

• UEl wiU then send infbmiU£2 that it requires resources to be reqi^^ 
(AMR) and RTCP flows CO continue. 

• UElandU£2activatesFDPcomests£orifaeRTP(AMEQandRICP^ 

• ^3Phen UEl has the required resources jt infanns the UE2 and tnE2 responds when it 
baa gpc the xeq[iikedresouice9b 

• UE2 sends ringiz^ to UEl and the RTP (AMB) and RTCP flows can start. 

llie example flow is shown with some more details in the folbwing 

however, that some messages has been omiaed for simifey (c.&, HSS interattions^ Go 
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5 Radio Network Realisation for the 
support of packet voice 

5.1 Overview 

The following is an overview of how a ooi):vers2tional IMS speech service for a 1Z2 Ishps 
AMR coded spcedi could b e realised in a 'WCDMA ndao access network with the 
overall assumptbn that the solution is based on 3GFP release 5. Hiis means that ROiiC 
header compression Is availaUe, but not the fuxther opticoisation features that are 
expected in 3GPP release 6 and onwards. 

For the first PDP context for t he SIP signalltng an interactive RAB is the natural choice. 
Hie establishment of this interactive RAB is done In the same wajras in eazller releases. 
Also the establishmem of a second loceFactive RAB is a rather suaight forsrard sohnioa 

One beneficial approach Is to establish plural new POP oontoos for a session using a 
sin^ PDP context request. This procedure also be beneficial in the situation where 
there is only a single niedia flow because established a media flow 
several PDP contexts. 

Then when it oomes to the establishment of the conversational RAB, there are a cou^ 
of optbns to choose among. In the 3GPP rdease 5 there will not in the RAB a«:;gnmi»nr 
be az^ detailed SOU infeixnatiQn, instead the RNC win receive a BAB assigpment with 
e.g mar SDU size, a bii rate that corresponds to die uncompressed RTP/UDP/IP flow 
and with a so\jrce descriptor that indicates speech 

• One of the pos^ilideswiuch seems to be the most naniral, is to follow what is 
requested in the RAB assignment. This g^vcs the possibiliiy to transfer the ROHC 
CTmpression synchronisation izifoixnation» Le., the ^^^^ri^-^npl information that is 
n ee d ed untfl the header compression functionality has started to compress the 
RTPAJDP/IP flow, without segmenranon and the corresponding build up of speech 
paduts la die RNC This however requires that a krarar spreading faa 

iiutially and that a chamid switctung is done after a couple of fr^ 
header conipressioa has synchronised. 

• Another possibility is to depend on that the source descnptor uidicates speech, and 
assign already from the beginning a higher ^readu^ Victor. In this case the longer 
initial Barnes has to be segmented whidi can be done either by using the 
umduiowledged RLC mode or by using the segmentanon gapah ilm^ in the ROHC 
header oonqniession. In this case there is a need for an active buffer managjemeot in 
the RNQ odierwise an additbnal speech del^ can be created. Hiis overall sohition 
however meam diat it Is already in the RAB assigiunent taken for granted that the 
actual compression possible withom really knowing this. Ericsson think that this kind 
of approach should be better supported in the standard before it is im^kraemed and 
that ^ shonid be part of the 3GPP xdease 6 and onwards. 



5.2 RABs and RAB realisation 

Froni what can be seen from the oiverview above and from the signaling flow, die 
folbwing RABs and RAB oomEnnattons has to be supported 

« Interactive RAB far the SIP agnalling 

• Two amuhaneous imenaiveKABs for SIP and forRTCP 

• Simultaneous interactive RABs for the SIP and a oonversazionalRAB forthe R3P 
flow 
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• Siimihaneouscwo mtenctiveBiVBsforiheSIP an^ 
coflversadoxial RAB for die KIP ibv 

Two of these RAB comhinarioiiSy Le^ the two interactive and the siraukaneous 
interactive and oonversational are ool^r needed during a short cransztion time in the 
transition phase from the first imencdve RAB for sigoaBbg to the state xidi^ 
three RABs are established 



Header compression 

The RCHC header compression will oon^rress the RTPAJDP/lP header from 60 octets 
to nonnaQy3 octets. The reason for not compressing it further down to noimally 1 octet 
is due to tha it is not possible to switch off the UDP chedksam in IPv6. This can most 
likdy be improved when UDP lite is introduced. 

Hiis means that before UDP lite is available, a 12.2 kfaps AMR coded speech service, will 
be optimised for 35 octets, but k also be ensured that a number of different sizes up to 
the max number of octets are possible. When more infbrmadon shall be transferred, 
channd switching can be used in order to temporarily increase the bit rate. In order to 
reduce the number of formats the possibilities within ROHC to limit the number of 
sizes of the header m;^ also be usai This m^ g^ve the possibiliQr to use the t 
RLCmode. Otherwise the less efGdent unarfeiowiedged RLC loode most be used 
ins tea d 



RAB realisation for the SIP/SDP sfgnalling flow 

For the signalling ficTw the alreai^ available interactive RAB is a suitable choice, Le., an 
interactive RAB combined with a 3.4 kbps signalling radio bearer. With the channel 
switching fmictzooality this RAB has the properties ihat the data rate is adapted 
amoimt of data that needs to be craosfezred Ihis adb^nadon also tdfi^ 
the coverage aspects and also the cunem loading in the 

RAB realisation for the simultaneous SIP/SDP 
and RTCP flow 

Also for the RTCP flow the ahnead)r existing interactive RAB seems to be the iia^ 
choice. For the combination of two mteractive RABs our view is that a oombinaxion on 
the MAC level is ^ropriate. THs g^ves the characteristics that the acvaiiable bit rae is 
shared between the two floxtrs and where one flow can use aU the available data rate in 
case the other flow has no data to transrnit. Abo this RAB comhinaTinn will have the 
same adaptation properties as is described for the single interactive RAB above^ in which 
case the combined data, rate is controlling the overall data rate. 



RAB realisation for the simultaneous SIP/SDP 
and RTP flow 

For the RTP flow a conversational RAB is needed. For the initial finames, Le., during the 
initial header compression synchronisation, there is a considerable larger amount of data 
to be transferred than during the oonnai state. Arid the proposed wa)r to handle this is a 
3GPP release 5 time frame is to make the RAB realisations for the RTP flow with two 
differem spreading factors, one that is optimised for the compressed RIPAJDP/IP 
flows in order to efficiemly utilise the resources and oric that is used in order to transfer 
the larger sizes during the synchronisation, of the header compresaon. This however wiH 
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have a dear disadTamage from a link biK^ poinc of view. For the combioation of the 
coaversational RAB whh the intenKccive Rf\B there is two separate tnn^ort channels, 
and then there is an addhional tran^rtdtannd fora3.4 kbps agnalling radio bearers in 
the same w^ as for the interaarre KAB aWe. An important issue here is to ti^ 
amount of datawzdnn the bounds given by the selected radio bearer, which is done by 
an sq>propriate sekccion of the aOowed transpoxt fonnac combinatbns. 



RAB realisation for the simultaneous SiP/SDP, 
RTCP and RTP flow 

The combination of the SIP, RTCP and KTP flow will be achieved by adding an 
interactive KAB to the realisations of the combination of a conversacbnal and interactive 
RAB described above, Le., two RAB realisattfwis with different qaeading factors as 
described above wiE be needed 

As the recparemeot differs for the RTO^ and SIP flows while at the same time the total 
bit rate should be limfrfH so that the RAB realisatbcs for diese £ows can be made with 
suitable ndSo bearers, most Hkeb^ for these RAB combination wiQ have different 
transpoxt channels for the two interactive KABs. The limitation of the total bit rate is 
done by limiting the allowed transport fomiat combinations. 

The overall RAB realisation forthe amuhaaeous SEP, KTCP and RTP flowwifl them be 
a combination of two interacxive andone oonversational RABs together with the 
signalltng radio bearera. Tbg overall RAB gealkanon xpill havm 4 tfgnywt fha«n#lgj ng^ 
for the ujnv eisa ii onal RAB» one for eadi of the two interacthre RABs and one for the 
signalling raffio bearers. 

6 Core Network Realisation for the 
support of paclcet voice 

Tlie main ta& of the oote oetwodt in the IMS service r n nt ^ mt }x> handle signaOii^and 

voice traffic fffirimrfyaaoss an IP network that also tranyat a wide vaifey 

data sessions widi dSffercnt ical<tn» or nra reai-iinie requ^^ 

wiD, at the edge of the network (GGSN), ensure conea mapping of the data flows inio 

die a^fc^nate GTP tunneb and ensure that agreed QoS are n'^"*? * n ^ Sutoe the 

3GFP R5 standard is still work in progress, the descriptbn bekiwjsprcliminaiyandxna^ 

be changed to ads^ to the €nal version of the standard. 

For IMS access, the terminal must fsrahlhh PDP context towards the appropriate APN 
and be assigned (by GGSN) an IPv6 address with an address prefix rehocd to the IMS 
domain. (The 3C^P R5 standaxd allows for stateful address allocation and statdess 
address alkyarion with one /64 Ipv6 address prefix per PDP context). 

Identification of the PDP context for SIP signalling bearer is not yet At^irnH} in the 
standard However it is e^eaed that all agoallii^is transferred on aspedSc PDP 
context to allowthe operator to select ^ transport or q>ecial charging for signalling as 
wdl as spedal policing/filtering towards IMS. GGSN wiQ filter the traffic firom this 
bearer and onl^ allow traffic to^rards P-CSCF(5) identified by the IPv6 address) on this 
PDP context. The P-CSCF IPv6 address (es) is oqjeaed configured throu^ the APN 
specification fisr the GGSN. The signalling bearer can be of type interactive; In the core 
netwodcand also on the netwoik between GGSN andP-CSCF, the QoS on IPlevd nuy 
use DiffServ class 'assured forwarding* with low drop precedence. The mapping will be 
generally configurate per APN and for the Gn netwoik. In the upUnk <£ceaion the 
s^nalling flow will be mapped into the signalling PDP context tunnel by use of the TFT 
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fOter h the GGSN. F<:SCF IPv6 address is the natuiai IP head^ 
fihsr. 

"Wlien the temuoal establish ses£oxis bjrusing SIP agpaJEog equivalent seoondaiy PDF 
contexts also be established fay the tenninal These PDF oontGOs wiD be ooirelated 
widithe SIP sessions throu^ signalling across the Go imer£ux (GGSN<- >P- 
CSCF/FCF) 9)iiulisg infomuDon cKhange). The GGSN creates aGPRS related 
dbar^jng ID per PDF con]» that win be used both by the S 
CDRcondatbn. lliis ID is also exchanged aooss the Go intei^ 
chargiag corrdatioa There are also additional requirements to co-oidioa^ 
on ^ level and GPRS bearer which requires the PCSC7 to inform GGSK of changes 
on the session level and vice ve tsa like session release and for GGSN to in&cm P-C^CF 
of loss of radio bearer etc Correndy, in the PS core necwodk there are no such session 
and bearer level co-rdatioa performed 

QoS and session destination infonnation exchange is also eiqpected across die Go 
imerface and the GGSN will use this information in the admission control for the PDF 
context and also to GhertrafQcfor the SIP related PDP contexts. The filtering is used to 
secure cocrea descxnason and source forthe traffic in the SIP allocated PDF oontes. 
Mapping ^m external traffic to PDF context vnSl be done using the TFT ^>ecified for 
the contest. Policing on PDF context level xfnJl also be used to prevent accidental or 
malidous flooding etc of the PDF contexts. The traffic will be madtied on the IP level 
wirh DiffScrv elates according the ^reed QoS throi^PDP context set-up and Go 
inf omation exchange. 

In the GGSN and in the rest of the network the SIP traffic will be mized with other type 
of traffic on <Ma^ levek The larger amount of the data traffic is ei^ected to be 
of type bad^iound (best effon) with very different real time requiremeot to the voice 
reacted traffic The Core and external network nodes will use the QoS toformation in the 
IP beaderto forward padtets according to QoS agreement Di^erv queuing scheduling 
and drop techniques are used in the forwarding. Voice traffic is eiqpected to be marked 
with £F (eaqpedited forwarding class and wiQ be secured low dday and low loss in the 
core network if the iig)bt dimfnfflontng and service levej affcanaeass (SL/^ are secured 
dsroug^ node and network configuranon. 

The nodes offered for die core netwtdt are designed to be able to hasde the traf& wh^ 
high c^iaotjr and low dd^. Ihe specific requirements for the SIP traffic widih^ 
conad message rate (PDP context combined with Go traffic) and advanced l eq uix ement 
on traffic filtenng etc mtroduces extra stram on spedal^ die GGSN. To handle thi^ die 
GGSN and the routers are buih indticEng hardware support to H*"^^ fui warding and 
QoS with low node ddsy for the prioritised traffic 

Piom the discussu>n abov^ it is visible that there are specific fimcdonal leqw^ 
the eastii^ Packet Core Netwodt in order to deliver IMS Servian 

• Core Network ^SN& GGSN) need to be aware of the FOP context used for SIP 
ogaaUing 

• Mtnirmim number of PDF ooateaas for every Padset Voice session is 3 

• Chygyng mrreJfltimi himffltng nvpr Cln intwfar^ attA hatHflmg ngjea'pff and bearer 

kvd interactkm described above 

• SDPine(£a type agreed on the session level are enforced in the PDF coiitexts/bearer 
via the media bincSi^ parameter 

• In order to perfonn the session and bearer oonrdadonftmcdoxi, the 
parameter iieed to be traiisfened from the session levd to the PS dosxiain via the 



• Discovery' of P-CSCF address via PS domain naedianism need to be resolved 

• Pdidng in differeritkvd adds to the oorj^plezity of the overall s^^ 
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• Charging priiKdpIes need to be finalised 

• In addition, there are open items related to Sendee Based Local Policy funoioDS such 
as 'open/dose gate' that need co be addressed beyond Rdease 5 tundErame; 

7 Characteristics and Possible 
Enhancements 

The following are some general characteristics regarding capadtjr, coverage and setup 
delays for the otidioed padset speech service oompared with the more dassical drcuk 
switthfld ^eeds service. 

The overall radio capaatywiD be lower than for a drcuxc switched speech service ^nxtial 
estimates show a 25% decrease). The following are some eaon^es of areas where 
accnnnes and unproveoients i^dacud to the capaci^ are expected. 

• By introducing IJDPIhe the ROHC header conq}resstonxvin be inipTOT 

• XJDPHtewiUalsogcvethepossibiUtytoffld^iiseof a^eechfraniethachasbit 
errors in the less important sub flows 

• By inttx»hiction of unequal enorprotecdon the requirements of the 

flows can be opdmised tocfividuany wiuch ^ves the possSblUiy improve the overall 
capacity. 

The coverage it wiD be lower than for a comparable dxaiic switched speech service. The 
most inqx>rtant improvements in this area is to make it possible to transfer the initial 
long headers without the reduced spreading factor. Examples of possibilities are 

• Make a s^mentarion of the initial longer frames 

• Reduce the initial frames by not having any psyload in d 

Regaxding the PS Coxv nowodt a can be noted that 3 PDP contexts would be needed 
per padtet voice session and hence the netwoik must be dimensioned to handle the PDP 
oontcsts and the associated sigpallini^ 

Regarding the call up times, an average call set ^> time (iq> to tinging) £oramobileto 
mobile call is estimated to be alxide bit more than 10 seconds ezdudingthe 
aitrfienricartoa Further work will of course be made in this area in order to improve this. 

8 Summary and Conclusion 

From what is described above the overall oondusion is that it is technically posaUe to 
have a radio necwQik that supports an 12Jd>ps packet ipeech seivx^ 
3GPPrd£a5e 5. However £rom the above: 

• Tliere are a number of assuioptiosis due has been madi^ and aO diese ^ fffi im j^ offf 
has of coune to be more thorougjbly woikedthxou^ 

• Tlierc are a number of areas where further wo A are dearly desirable in order to 

improve the peifonnances, and this is also what is cmreottytakingi^aceia die 3GFP 

fl fiH ^yt^f ^^^ ^^^ 

• T^gfg aff* also a mimber <!iff«igfit dedfions that hpg to bc made in order to dffine 
such service. These decisions has to be made on a global scale in order to secure the 
interoperability and the availabiliiy of terminals (e.g^ fox the padset voice service the 
^pHcation/texminal must have enough knowledge to activate sepams PDP contexts 
for the RIP, RTCP and SIP/SDP fbws). 
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• llie basis for these dedsbiis^chaitgeu the 3GFPnaiula^ 

seve ral o f the sdecDoas of the di£Ferem altemadv«$ would be different when based 
on 3CPP release 6 maead of release 5. 

llxis means that a padcet vdce service based on rdease 5 win 
h^pen as a inass maikec servke. Inscead the mam stream soimions wffl 
3GPP rdeases where all the main issues has been seeded 

llie design of a system sohition for an (^>dmised mainso^ 
an Iterative pxxjcess where aU pans must betaken into consideration. IMS is one 
important subsjrstem in the service ddhreiy; However, it must also be undostood how 
the ;^pli£adon, UB, UTRj^ and PS CN woiks toge^ 

consisteat service to the end user. The total system view has so far been somewhat 
n^^ected in 3GFP and henoe k is veiy difficult to see how opdmised m^^ 
conversational services can be bmh based on release 5. 

It should also be noted that this pa^ od]r addresses a pan of the whole sd\idon, a 
number of issues to accoum fbn 

• sinxdcaneoustiseofpackec voice and other services 

• what h^)penS V/hen the system is coverage limited ratbgr than capaaty llm tf-^ 

• how- to ensure packet voice operation in h^ load OQiiditions 

9 Way Forward 

The packet voice service scenario is Ericsson's intefpretanon of a service that could be 
interesting for operators. Funher Ericsson has made estimated what will be ?nr^idfd die 

rdease 5 standards. Aiy changes in the service scenario, the standanfe or other 
assumptions vezy well influence the design choices and hence the implications in 
tenns of capadiy, coverage and service qua&iy. 

Ericsson would like to further invest^e possible IMS service scenarios induding voice 
and wuuld encourage broad partidpacion in continued discussions to aid all parties 
understan<£ng of the implicadons on the AppEcadonSp Temmoals^ UIKAN and PS CN 
in tcmis of both standards and products. ^ 



SIP Mobile Multimedia System Description - PAS 



1 Introduction 

This paper describes on a high level the Ericsson solution of a complete mobile 
multimedia system for supporting different media using IP technology. 

It starts with Section 2 is an description ovennew of the architecture for the complete 
mobile multimedia system. The main focus Is on the IP Multimedia Subsystem (IMS) 
architecture. The other sub-system components are also described but the focus is 
then on the expected functionality needed to support IMS. The main drivers for 
Introducing IP technology into mobile networics: new services and a common transport 
technology. It then gives an overview of the mobile multimedia system focusing on the 
core networi( architecture. 

Secdon 3 describes system concepts that are necessary or adds value to IMS. 

Section 4 gives a high-level view of what products Ericsson can offer for a complete 
mobile multimedia system. 

Section 5 gives a brief migration view how an eariy IMS system can be migrated to 
real-time conversational SIP based IP multimedia system. 

2 System Architecture and Interfaces 




Figure 1 System Overview 
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Figure 1 shows a high level view of the system components required in order to 
deliver services to a SIP mobile multimedia system. The role of these system 

components is described below. 

2.1 Terminals 

2.1.1 Temninal Functionalltv 

In the same manner in which the terminal will connect to different core networks, there 
will be a number of terminals which can also connect to the IMS network. Tenminals 
connecting to the IMS network will have a greater role to play in supporting the end- 
users' conununication needs and will support all or parts of the following functionality: 

• SIP/SDP as defined by IETF and 3GPP. 

• IPv6 profile for cellular networks for IMS 

• Multiple simultaneous PDP contexts (and RABs), 

Cn • Order mapping of the media flows to the conrect PDP contexts. 

[3 • Conversational QoS. 

• Header compression (ROHC) 

• SIP header compression 

• Java Based tenninal service creation environment. 

|>9 • SIP based presence and instant message applications. 

hii • IPv4 and iPv6 for non-IMS applications 

!^ • Support for non-IMS application {e.g. WAP 2.0, MMS) 

jly • Ability for the IMS application to invoke other applications (e.g. Streaming) 

O • integrated camera 

te • Security functions (TLS for WAP. IMS AKA for IMS). 

a 

rU 2,1,2 Terminal types 

The temriinats accessing IMS are segregated into two basic types - the smartphone 
and the split user equipment. 

The smartphone is an tightly integrated device containing the UMTS radio functionality 
and the IMS application. This is an evolution of the tennlnals fliat mobile users are 
familiar with in 2G networks. The level of functionality supported in the smartphone Is 
dependant on the market segment the phone is aimed for, but may include 
applicatbns streaming, camera, WAP and messaging. These phones are mass 
market phones. 

The split user equipment has two components. One component is a device containing 
the UMTS radio functionality, and may support a number of applications, however the 
IMS application resides on another device. This component could be a laptop or a 
PDA, and may cover e.g. Microsoft XP Messenger, which is gaining popularity as a 
SIP based application. 

2.2 UTRAN 

The UTRAN ptays tiie role of controlling the radio networic resources. In order to 
support real-time conversational SIP based IP multimedia the base stations and RNC 
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are expected to provide new fieatures. Some of the more important functionality 
expected are listed below: 

• Header compression (ROHC) 

• Conversational RAB for the transport of Voice and video media 

• Interactive RAB for the transport of IMS signalling (SIP signalling, and possible 
other supporting signalling). This might be in the fomi of a Signalling RAB when/if 
standardised. 

• Transport for RTCP signalling. 

• Flexible RAB combinations allowing simultaneous flows for media, signalling and 
other sen^ices (e.g. WAP). The number of simultaneous flows is dependant upon 
the end-users service experience that will be provided to Hutchison's subscribers. 

Z3 IP Access Network 

The main task of the IP access networic In the IMS service context is to handle 

signalling and voice traffic efficiently across an IP network that also transports a wide 

variety of other data sessions with different real-time or non real-tme requirements, 
g The core networic will, at the edge of the networic (GGSN). ensure conrect mapping of 
r| the data flows into the appropriate GTP tunnels and ensure that agreed QoS levels 

are maintained. Since the 3GPP R5 standard is still work in progress, the descriptton 
2 below is preliminary and may be changed to adapt to the final version of the standard, 
iia For IMS access, the terminal must establish a PDP context towanjs the appropriate 
i.j APN and must be assigned (handled by GGSN) an IPv6 address. 
» Identification of the PDP context for SIP signalling bearer is not yet defined in the 
O standard. However it is expected that all signalling is transfened on a separate (?) 
!|U PDP context to allow the operator to select free transport or special charging for 
|:3 signalling as well as special policing/filtering towards IMS. GGSN will filter the traffic 

from this bearer and only allow traffic towards P-CSCF(s) (identified by the IPv6 
jig address) on this PDP context The P-CSCPs IPv6 address(es) towareis the temilnal is 

expected to be configured through the APN specificatfon for the GGSN. The signalling 

bearer can be of type interactive. 

When the terminal establishes sesstons by using SIP signalling, it will also establish 
secondary PDP contexts for the transport of the bearers. 

2.3,1 QOSN 

The GGSN provides an interface between mobile radio core networics (GPRS and • 
UMTS) and other packet data networks, such as the Internet, corporate intranets, and 
private data networks. In this role, the GGSN is responsible for session management 
within the mobile network, as well as for en<:apsulation and de-encapsulat'on of bearer 
traffic sent to and from Sen/ing GPRS Support Nodes (SGSNs). The GGSN serves as 
the IP access node for IMS. 

Examples of GGSN functions that will or might be used to support IP multimedia are: 

• VPN (IPSec and MPLS) 

• IPv6 

• Routing protocols (OSPF, BGP-4, IS-IS etc) 
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• QoS (multiple mechanisms (e.g. diffserv) applied at the per-PDP-context level and 
at the aggregated-trunk level) 

• Go functionality required to support charging.. 

• Multiple PDF contexts per subscriber. Each context will then have a separate IPv4 
or IPv6 address. 

• Several secondary PDP contexts per primary PDP contexts. By using a secondary 
PDF context a user will be able to have more than one PDF context per IP 
address, with a different level of QoS if necessary. 

• Security (e.g. IPSec, IKE) 

2.4 IP Multimedia Subsystem 

Ericsson's networi< solution for ilVIS is based on the separation of functionality Into a 
control layer and a connectivity layer as shown in Figure 2. 




Figure 2 Ericsson high level soitition for IMS 

The control layer hosts control servers such as the IMS sewers (CSCF. MGCF. 
BGCF. SGW and MRFC). The control servers may also handle functions like mobility 
management, security, charging, conferendng and interworidng towards external 
networlcs on control plane level. The HSS is the subscriber master database for the 
PS domain and IMS. The main protocol in the control layer is SIP. SIP allows several 
transport protocols, UDP is mandatory, which is supported by the Ericsson products. 

The connectivity layer is used for media and includes media gateways and media 
mixing functions. The media gateways provide different l<inds of interworidng for the 
media, including interworidng between different transmission technologies and 
IntenA/ortdng between different media formats. 

The interface between the control layer and the connectivity layer consists of plain IP 
routing or gateway control protocols such as H.248. MRFC and MGCF use gateway 
control protocols to control media manipulation and intenAK>ricing in MRFP and MGW. 
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The IP access gateway (GGSN) is considered to be part of the connectivity layer. 
Although It contains some control functionality, the IMS functionality of the GGSN lies 
in providing IP connecth4ty for the IMS control (e.g. SIP, Dianneter and H.248) and 
media. 

The routers and switches in the IP Infrastructure provide transport capabilities for both 
tile control layer and connectMty layer traffic. 

g,4.1 C3CF 

The IP multimedia system is built around the Call Session Control Function (CSCF). 
There are three different CSCF types: the IntemDgating CSCF (l-CSCF), the Proxy 
CSCF (P-CSCF) and the Serving CSCF (S-CSCF). 

The P-CSCF is the first IMS point of contact for the User Equipment (UE). The P- 
CSCF forwards the SIP messages received from the UE to a CSCF in the home 
network (and vice versa). The P-CSCF may modify an outgoing request according to 
a set of provisioned rules defined by the network operator (e.g. address analysis and 
Q potential modtficaticn). 

W 

l,n The l-CSCF function forms the entrance to the home network. It provides flexibility for 
"p selection of a S-CSCF, and may hide the inner topology of the home network from 
Other networks. 

m 

The S-CSCF performs the session control services for the UE. This includes routing of 
L originating sessions to external networks and routing of temninating sessions to IMS . 
I^y access network (P-CSCF). The S-CSCF also deddes whether a SIP Application 
i;2 Server is required to receive information related to an incoming SIP session request to 
i;g ensure appropriate service handling. The decision at the S-CSCF is based on 
1:3 infomiation received from the HSS (or other sources, e.g. appllcatfon servers). The 
I'U identifiers of the application server(s) are also received from the HSS. 

All CSCF functions may generate chaining tnfonmation. 

2.4.2 HSS/SLF 

The Home Subscriber Server (HSS) is an evolution of the Home Locatfon Register 
(HLR) and Authentication Center (AUC). It holds the subscriber's profile and keeps 
track which S-CSCF is handling the subscriber. It also supports functions like 
subscriber authentlcatk>n and authorisation (AAA). 

in networi^ with more than one HSS, the Subscriber Location Function (SLF) is used 
as well. The SLF assists tiie control layer with the location of tiie HSS server where 
subscription information resides for a specitic subscriber. 

2.4.3 MRF 

The IVIedia Resource Function (MRF) contains functionality to allow manipulation of 
multimedia streams, it can support functions like multi-par^ multimedia sen/ices, 
multimedia message playing and media conversion services. 3GPP has dedded to 
split the MRF into a control part (MRFC) and a pnx:essing part (MRFP). 



2,4-4 BGCF 

The Breakout Gateway Control Function (BGCF) selects the network in which 
breakout to the GSTN network Is to occur. That network may either be the home 
network, the visited or another network. If the IntenA/orking is performed in the home 
network, the BGCF selects a Media Gateway Control Functton (MGCF). If the 
interworWng is to be perfonned in another network, the BGCF may select another 
BGCF or an MGCF. 

2.4.5 MGCF 

The MGCF provides intenvorking between the SIP session control signalling from the 
IMS and ISUP/BICC call control signalling from the extemal GSTN networks. It also 
controls the media gateway that provides the actual user plane interworking (e.g. 
convert between AMR and PCM coded speech). 

2. 4. 9 SQ 

The signalling gateway (SG) provkles bearer interworking fortiie control s^naliing 
(e.g. ISUP/IP-ISUP/TDM). 

2, 4J ivigw 

The MGW provides media stream manipulation towards PLMN/PSTN/H.324M/H.323 
networks. 

2,4.9 PC F 

The policy control function, which is co-located with a P-CSCF, tenrunates the Go 
interface. The Go Interfece between the GGSN and the PCF allows for bearer and 
session co-ordination (for the support of charging correlation); notification of radio 
bearer toss or modificatbn; policing of the media flow destination and authorisation of 
the PDP contexts for that session. 

2-4.9 IPverstonsuDDort 

The Ericsson SIP based multimedia solutbn support IPv6 according to the 3GPP and 
IETF standards. In additton, the solution can be configured to support an IPv4 
terminal (split temiinal). 

Note: In the IPv4 configuration, the Ericsson SIP based IP multimedia network 
behaves as IPv4 SIP proxies, the sesston and bearer levels are not correlated. 



2.5 Service Network 

2.6 Service Network 

The Ericsson service network is built up from individual components that can co-exist 
with other service network nodes and concepts; or benefit can be gained from the 
Ericsson service network framework by utilising common subscriber management and 
common database handling. 
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ZMA Sqrvipg NetworK Frqmewofk 

SNF Service Network Framework is a framework for components residing in the 
sen/tce network. While an Ericsson concept, the SNF is an open« IP based application 
environment using standard protocols and industrial practice to deploy a Service 
Networie 

Some of the concepts that ttie SNF Is built around are: 
Common Provlstoninq 

There should be only one point of access for the end-user and one point of access for 
the operator to manipulate the applications data. The end-users to personalize his/her 
sen/ices, the operator provision the service and default data. The end-user should 
have a possibility to subscribe/unsubscribe to applications provided for the users by 
the operator. One of the key components for common provisioning is the common 
directory. The Common Directory provides a single point of access to subscriber data, 
Q resident in many different databases. Applications can now access information stored 
by many other applications in a secure manner. 

II' 

y The Service Network Operational System (SNOS) is the single point of O&M tor the 
„ Service Network. SNOS is a fault, performance and configuration management tool. 

Q 

ry ^nabterg 

i;a Enablers aid In the development of Mobile Internet sendees, it provkJes multiple 

Q functions and features needed in the development and customisation of sen/ices. The 

I'U enablers are vital in making a horizontally layered architecture possible. Each enabler 

Interfaces with core and business support systenos to provide APIs (Applk:ation 

Programmer Interface) for developers to use. 

Z32 SIP Application Servfir 

A key component of tiie SIP based IP multimedia service network is the SIP 
application server (SIP-AS). The Ericsson SIP-AS contains a sen/ice creation 
environment supporting software development kits (SDKs) which can be used to 
access ttie SIP applications, but also otiier enablers. 

The SDK is built around Java interfaces supporting ttie J2EE applicatton environment 
on tiie J2AS (Ericsson J2EE Application Server). The Interfaces have a common look 
and feel making it easier for the developer to find functionality and classes in a well- 
structured environment 

The diagram below describes how the SDK provides integration to the different 
enabler components of the Service Network Framework. 
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Protocol 




Can be any pratocoi apiKopriats to systsm componem (HB^ 




Figure 3 Example use of StP-AS and enabiers. 



J2AS Is implementing the J2EE standards and APIs to support the SIP protocol. 
Through the SDK, application developers do not need to know what middleware 
technology is implemented towards sen/ice enabiers. 

2.6.3 Presence and Instant Messaging 

Ericsson's presence solution is based on presence infomnatlon from a number of 
sources including CS domain, PS domain, mobile positioning centre, as well as 
infomfiatton from the IMS. Instant messaging is communication between two users, or 
a community of users. Community based instant messaging Is supported with the 
presence and instant messaging application. 

Ericsson's system supports the presence and instant messaging (PIM) application on 
the J2EE SiP application server. The PIM application for IMS is integrated with 
Wireless Village (WV) PIM application in order to co-ordinate the mobile PIM 
communities and re-use of WV application infrastructure and databases. The PIM 
application supports the IETF "SIMPLE" approach for intenworidng with other PIM 
communities. 

2.7 IP Infrastructure 

When providing an IP infrastarcture for IMS, the objective is to let all sendees (e.g. 
IMS, fixed-line services, ISP sen/ices, content delivery transport) use the same IP 
Infrastructure. 

The basic assumption is that similar real-time characteristics are wanted for this multl 
service IP infiBStructure as the characteristics that are offered with TDM and ATM 
networks. 

The IP infrastruc^re is structured Into two main tiers: 

• Site tiers where network elements using local area technology are connected to 
the IP backbone. 

• An IP backbone tier cam'es all traffic between the sites using wide area 
technology 
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2-7.1 Sites 
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A site has a local area iP infrastructure, which Is connected to the various elements at 
the site and connects to the IP backbone trough edge routers. The site is typically 
using Fast Etiiemet, Gigabit Ethernet LAN switches etc, with capabilities of using 
VLAN t(3chniques. The IP infiBstructure of the site is duplicated to guarantee full 
availability. 

The edge routers connect the site to the IP bacl^bone, and contain advanced functions 
for defining a service agreement between the site IP network and the IP backbone. 
This Includes e.g. MPLS LER function, 2547bis, BGP, and various filtering functions. 
A site typically uses a pair of edge routers, connected to different core routers in the 
IP backbone. The mapping of these different site types on the IP backbone network is 
shown in Figure 5. 

Ericsson divides the sites into 3 site types capture the needs of an operator. Other site 
types can be defined depending of specific operator conditions. 

• Primary Site 

is the most important site type and includes a "complete sef of functions 
needed for a UMTS networic: IMS servers, media gateways, GPRS support 
nodes, and radio access network controllers. A primary site may also include a 
service networii configuration. 

A networic can have several primary sites for redundancy load distribution 
purposes. 

• Secondary Site 

contains media gateways, GPRS support nodes, and radb access network 
controllers. If suitable in the network secondary sites can also have peering 
connectk)ns to other networks. 

• Access Network Site 

includes media gateways and radio access controllers, and is used to 
concentrate the traffic before going to a primary or secondary site. 




Figure 4 Example of a Prlmaiy Site 



2.7.2 IPBacM?Qne 
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The IP backbone is designed for simple high-speed pacl^et transport, and is typically 
built with large backbone routers interconnected witti fast links, e.g. Ericsson's AXI 
520/580 routers interconnected with gigabit links. 

The assumption here is that one single operator runs the IP backbone. The routers 
support different class of sen/ices and layer 3 VPNs. 




Figure 5 Sites interconnected by IP backbone 



3 System concepts 

3.1 IPv6 

To provide enough IP addresses to all connected terminals it is envisaged that 
operators would provide IPv6 for end-user and applications. For the IP backbone 
there will be a tong transition period when both IPv4 and IPv6 will be used. Ericsson 
products will Indude dual stack implementattons. Features for handling IPv6 packets 
In different IPv4 tunnels will be provided. 

3GPP IP Multimedia Subsystem has been defined to use IPv6 only. The diagram 
below shows on a high level where the impacts are in the existing system, mainly the 
temiinals and GGSN. As peer-to-peer, machine to machine, push, presence, 
multimedia and mobile focused service communication become dominant in the 
market, use of IPv6 becomes a natural way forward. 

The successful transition from a IPv4 dominant Internet to IPv6 will be a long process 
and proper and adequate transition mechanism will be a key enabler of such smooth 
migration. Ericsson has focused on a strategy where 

• all fPv6 enabled nodes will be dual stack, including terminals, 

• IPv6 will be introduced in the applk:ation layer first (e.g. IMS), thus enabling 
gradual and controlled introduction of IPv6 allowing gain in customer experience 
and knowledge on practical deployment of IPv6 

• migration and transition mechanism are provided to co-exist with IPv4 deployed 
networics 
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• All intermediate steps are directed towards long term goal of moving into IPv6 in 
the transport plane, end to end and top to bottom when IPv6 is dominant in the 
market. 




Figure 6 Possible rollout scenario 



3.2 Quality of Service 

The starting point for QoS should be the end-user and end-user satisfaction with 
provided services. This is caicial for real time IP services such as voice, video, and 
music. But to provide ^is satisfactory quality, a chain of mechanisms has to be 
engaged on the path from application to application. Ericsson's products provide a 
large number of advanced QoS features on the different segments of the chain. 

3.2.1 QoS In UMTS 

In this chain the radio and the resource control of radio resources is crucial. Ericsson's 
products for UTRAN and GPRS supports the advanced QoS handling required when 
volume IMS services are provided. 

3GPP has standardised a QoS model and architecture, supported by a set of detailed 
attributes, to be used to configure and control the traffic from the mobile station to the 
network. Four traffic classes is defined: 

• Conversational 

• Streaming 

• Interactive 

• Background 
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Each class is defined to match a typical application scenario. Conversational traffic 
class is optimised to support a human-to-hunian real time conversation of voice or 
video, Streaming traffic dass is optimised to support streaming video or audio 
applications. Interactive traffic class is optimised to support non real time, typically 
TCP based, interactive user flows. The purpose of background is to provide a data 
transport where there are no demands at all on delay. 

Ericsson's UTRAN and GPRS products supports all traffic classes and provides 
efficient transport of the user flows over different transmission media, WCDMA, ATM, 
IP, without compromising the end-user quality. 

3.2.2 QoS in IP backbone 

Traditionally IP backbone networks had been implemented only relying on best effort 
forwarding and large enough bandwith. Together with the congestion avoidance 
mechanism in TCP, this Is an adequate and cost effective principle if the data 
i'Si transported, or at least the greater part of the data, is non real time (TCP/IP) traffic. 

□ 

l,y 3.2.2.1 Congestton control mechanisms 

When IMS is implemented there will be a need for the IP backbone to efficiently 
jl^ transport large volumes of real time data. Note this real time data does not use TCP, 
f' I and therefore will not be able to benefit from the congestton avoidance mechanisms in 
, TCP. 

O 

ry Over provisioning of the IP backbone is therefore not considered a viable, general 

O solution for providing QoS in an IP backbone supporting a volume of IMS services. 

(3 Additional means for ingestion control are necessary to improve network efficiency. 

9 

I'U The extent to which over provisfoning can be reduced depends on the grade of 

sophistication of the congestion control mechanisms. The amount of over provisioning 
needs to take into account fault situations (link or router failures), traffic concentrations 
In conjunctton with 'abnormar events, provision of capacity for best effort IP traffic 
(must never be completely starred), etc 

The congestion control mechanisms supported in Ericsson's IMS solution is: 

• Admission control in the nodes processing IMS user data, I.e. GGSN, MGW, 
MRFP 

• DiffServ differentiaton in the edge and backbone routers 

« Ability to define a bandwith limit when scheduling prioritised queues 

• Ingress policing of extemal interfaces (where admission control is not trusted) 

• Ability to use traffic engineering to control and dimension the network (e.g. by 
using MPLS) 

3.2.2.2 Admisskm Control 

The nodes involved In IMS user data transport over the IP backbone are GGSN, 
MGW and MRFP. To be able to dimension the IP backbone networic and to avoid 
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overloading the backbone routers with real time traffic these nodes support an 
admission control function. 

The data processing function in GGSN, MGW and MRFP have a flow context. For 
example GGSN identifies to which PDP context a packet belongs received over Gn: 
MGW. when gating between CS network and IP network, makes use of the circuit 
concept of ISUP/ISDN. 

Before accepting a request for a new flow GGSISI/MGW/MRFP check that there are 
available IP resources matching the required fonwarding quality of the flow. The 
required fonvarding quality con-esponds to DiffServ PHB and is retrieved from UMTS 
QoS attributes (PDP context) or media type description (received from MGCF/MRFC). 
New flows are requested by the session/call control function: PDP context activation 
for GPRS and the bearer request that is as a part of IMS session establishment 
procedure (from MGCF and MRFC). If the resource utilisation limit for a specific 
fOHArarding quality is reached in GGSN, MGW or MRFP, requests for PDP context or 

Q bearer will be rejected. 

W 

in When a request for a PDP context / bearer is accepted the required forwarding quality 
is stored in the context for the flow (GPRS PDP context/ bearer context). During user 
data transport the user flows will be 1 ) classified according to their required fonflrarding 
quality, fetched from the context 2) mapped to DiffSen^ PHB and 3) marked with 
corresponding DHCP. 

£3 

i'y The IP fonwarding in edge router and core routers will only be aware of the PHB 
l;3 retrieved from DSCP of received IP packet The flow context is transparent for the 
i;a routers. The IP networi< should t>e dimensioned so that it has capacity to fonA^ard all 
O DiffSen/ traffic of a certain dass according to the defined PHB of tiie class as long as 
ru the conflgured resource utilisation limit is not exceeded in GGSN, MGW and MRFP. 

3.Z2.3 DiffServ 

DiffServ constitutes a comer stone for handling QoS at the IP-layer in the proposed 
QoS-solution. As said above the nodes involved in transport of high volume real time 
IP traffic perfonn the DiffServ maridng of an IP-packet 

The edge and core routers are configured in such a v\^y that «ie intended traffic 
scheduling and priorifeatfon is obtained for packets according to their DSCP. The IP 
packets are classified and fbnvarded to a suitable outbound queue, on which the 
scheduler operates. 

To confomn to the dtmenstoning rules defined for the networic, the scheduler should be 
configured with a bandwidth value per queue, e.g. assigned a percentage of the total 
available bandwidth and possibly also a priority. It is essential that mechanisms In the 
router prevent starvation of low priority queues, 

Ericsson's AXI 520/580 routers and the embedded router in MGW, MRFP and GGSN 
provide rich mechanisms for Dif^rv bas^ fonvarding: e.g. queuing, scheduling and 
packet marking/dropping at the internee level. Ingress policing, queue selection, 
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precedence field rewrite/remarkp Random Early Detection (RED) and strict priority 
queuing are other conf^urable functions. 

3.2.14 Principles for network dimensioning, an example 

There is a trade off between sophistication of tfie congestion control mechanisms and 
the extent to which over provisioning can be reduced. The cost to maintain and 
configure a sophisticated congestion control mechanism in a large networlc may be 
significant, but also the cost for transmission links if the amount of oveiprovisioning is 
high. 

Ericsson has during the last years worked wi^ the issues of dimensioning a multi 
service IP infrastmcture, and found that the following prindples is a good balance 
between complexity and IP resource efficiency: 

The resource utilisation limit in a node is configured as allowed bandwidth per 
5;«j forwarding quality" and Interfece. The interface is the interface in the edge router of 
Q the site that is used for the IP flow (see chapter 2.5.2). In case of VPN or redundant 
l,y links, several interfaces may have to be configured in the admission control function, 
in The accumulated load retrieved from UMTS QoS profile (GPRS) or the media type 
"S description (IMS) is compared with the configured bandwidth. 

This model offloads the dimensioning tool and configuration management from 
configuring a full mesh networic between all GGSNs, MGWs and MRFPs. The 
increase in level of overprovisioning is heavily dependant on number of sites and 

fy networic topology, but simulations has shown that the increase will be a factor of 2 -3, 

f J compared to a full mesh networic, for typical topologies. 

Q 3.2.2.4. 1 Static versus dynamic network dimensioning 

ru The dimensioning model and admission control principles described atx)ve assumes 
statfc configuration of the admission control func^ons of GGSN, MGW and MRFP as 
well as the interfaces of edge and core routers. The admission control function in a 
node will statically be assigned a fraction of the total bandwidth of an outbound 
interface of the edge router, the bandwidth level selected so that the interiiace is not 
overioaded and prevention of starvation of best effort traffic. 

Ericsson recommends static resource configuration as the first step when building a 
multi service IP network, mainly because the lack of widespread muitivendor resource 
control protocols and lack of full-scale experience of dyriamic resource control 
algorithms for IP networtcs. 

Dynamic handling may be introduced stepwise as the network grows and new 
resource control mechanisms evolve. 

3.2.3 End-to-end QoS coordination of MS sessions 

The detailed mechanisms, segment by segment that allows the operator to control the 
quality provided to the end user of IMS service has been detailed above. 



The last piece of the QoS puzzle is the feed back to the end-user. When establishing 
an IMS session to a remote IMS user, the end-user would like to know if there are 
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enough resources, all the way to remote application, before the sesstan starts. The 
model for session establishment selected by 3GPP is based on QoS assured SIP 
protocol option. During session establishment SIP messages are exchanged infomiing 
the remote side if the bearer level QoS set-up was successful or not 

If for example an admission control function rejects the requested QoS level, SIP QoS 
assured protocol option supports that the side that fails infomis the remote side of the 
failure. If this is not acceptable the IMS application in the tenninal may tenminate the 
session, but it is also possible for the two participants to try to continue on best effort 
basis, i.e. no longer using the QoS assured protocol option. 

3.3 Security 

3.3.1 Accggg SecMiity 

The IMS access security Includes 
CP - mutual authentication between the user and the IMS home network. 
O - confidentiality (optional) and integrity protection between the user and the IMS 
access network. 

^5 For the integrated terminal, the authenticatton is based on IMS AKA, following the 
3GPP standards. For split terminals, which do not have access to the UlCC, then 
Jl! standard SIP meOiods are supported, for example HTTP digest (HTTP basic is not 
y recommended). 

ii 

□ Note: The standardisation of the IMS access security Is still in progress in the 3GPP. 

ru 

Q 3.3.2 Network Domain Securtty 

^0 The network domain security (NDS) provides Authentication; Replay protection; 

|;3 Integrity protection and Optionally confidentiality protectfon between network domains, 

^ and optionally wrthln a network domain. 

In order to support NDS between networks. Security Gateways (SEGs) are 
provisioned on the border of the operators networic, protecting the tmsted networic 
from the outside, untrusted network. 



Trusted ii^ork 



Untrusted netwoik 



Figure 7 Network Domain Security Support 

The security gateway fun^onality consists of 
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• a filtering firewall, 

• the actual secu rity gateway and 

• a stateful firewall. 

The task of the filtering firewall Is to act as a first line defence against attacks from 
untrusted networks using basic packet filtering firewall capabilities. The filtering 
firewall can be e.g. an Edge Router. 

IPsec VPN tunnels are used between co-operating SEGs. The stateful packet 
Inspection firewall constitutes the second line defence for all the traffic not using IPsec 
VPN tunnelling, but also for the traffic coming via IPsec VPN tunnels as attacks 
through the tunnels are also possible. Stateful Inspection of TCP sesstons and UDP 
pseudo sessions is used to increase security. 

Note: The standardlsatkjn of the Networtc Domain Security is still in progress in the 
m 3GPP. 

O 

/.U 3.3.3 Site Security 

m 

A site must have the security functions that are necessary to support the operator's 
j;g security policy. A site In this context is an IP Infrastructure Primary Site described 
j'^ eariier including the IMS nodes. 

ii 

(3 The security functions t>elow are useful functions to support a security policy, 

ru 

i|3 3.3.3. 1 Perimeter protection 

(0 Firewalls are used for perimeter protection and protect fijily or partly against general 

t3 IP threats. 

ru 

Firewall filtering is done based on various parameters e.g. port numbers, IP 
addresses, interfaces (in, DMZ, out) and protocol (TCP, UDP. SCTP etc): 

Ingress filtering should be used to check the source IP address to reduce the 
possibility of denial of seF>rfce attacks. This should then be enabled in GGSN. 

3.3.3.2 Hardening 

Hardening refers to the process of modifying system resources to be more secure to 
protect internal nodes to some extent if the perimeter protection is penetrated or from 
insiders. 

3.3.3.3 Audit trail recording 

Audit trail recording or logging must be used in a system to be able to detect 
suspicious network activity. 

Logging of relevant events defined by the security policy (e.g. access attempts, 
system changes, indication of networic reconnaissance) is included in networi^ nodes. 
Filtering Is possible to apply in order to reduce the sizes of the tog files. Those files 
shall be securely stored. 
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3.3.3.4 Intrusion Detection Systems 

An IDS should be used to automate analysis of the audit trail files. Ideally a successful 
IDS can recognise both suspicious activity and denial-of-senrfce activities and invoke 
countenneasures against them in real time. 

3.4 Logical Networks 

Different types of information are exchanged between the network elements. 
Traditionally, separate r^etworks were used to handle these, e.g. STM/TDM, ATM, IP 
and SS7 networks, each with well-defined quality of service and with little or no 
connectivity among them, thus giving complete separation of traffic between the 
various infomiation flows. 

When these networks converge into a single multi sen/ice IP network in which IMS is 
a part, the IP infrastructure must be capable of handling all this information exchange. 
At the same time it must facilitate for necessary traffic separation and assurance of 
sufficient quality of service for the different traffic types. Ericsson has thoroughly 

ifi studied these issues and has coined the term logical networks to conceptually divide 

p the independent traffic types. 

i'^ Each logical network encompasses a particular Infomfiation flow between a designated 
^'2 set of functional entities residing In the network elements. Each logical networic has 
X both a set of requirements on the infrastructure with respect to security, connectivity, 
|;g QoS, networic availability etc and a set of characteristics that might Influence other 
l,y flows, such as bandwidth demand, burstiness and possible security threats to other 
I. logical networics. 

a 

rU 3.4. 1 MaoDinQ of logical networics to VPNs 

lip 

|;| Ericssons definition of different logical networtcs is based on the different functions in 
the system (e.g. exchange of signalling infomiation, O&M. exchange of user payload 
etc), tiieir characteristics and requirements. Some logical networi<s have similar 
requirements and can be combined (e.g. SIP signalling and traditional SS7 signalling) 
otiier logical networics need to be separated (such as user payload from signalling and 
O&M traffic). 

VPN technologies can be used to separately transport the different logical networics 
on the same physical infrastructure. Each logical networic has different requirements 
on the IP networic. so different VPN technologies should be used for different types of 
traffic. One simplified mapping is shown in the Figure 8. BGP/MPLS IETF RFC 
2547bis (witii extensions to IPv6) is used to separate logical networi<s Into layer 3 
VPNs in the bacWaone. Witiiln the site, separation is perfbnned with VLAN tagging. 
This gives similar separation characteristics as in an ATM network. 
Also ottier mappings like e.g. IPSec VPNs can be used where privacy is required.ln 
some cases VPNs can be avoided and substituted by filtering and access control lists 
in tiie routers amj client nodes. 
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Figure 8 Logical Networks mapped to VPNs 

Effective separation into VPNs must be supported in the networl< elements. The 
Ericsson platfomis used in the IMS architecture are designed to support multiple 
connections to different netwoite and are thus ideally prepared for this task. 

3,5 Addressing 

The SIP based IP multimedia addressing Is a collision of two familiar worids. E.164 
numbers, which is applicable in the 2G mobile networks, are available, and in addition, 
the "Universal Resource Locator (URLs), which take the form of email addiesses are 
supported. As an example, a valid SIP address might be 
siD:name.sumame<S>fy>mpanv.com. which implies the use of DNS to map host and 
domain names to IP addresses. This is a key aspect of the integration of SIP with 
web and mall-enabled technologies, which are already familiar with the concepts of 
URIs and their interpretations. 

The dose connection between SIP and DNS facilitates interoperability with telephony 
systems as well as their addressing mechanisms. Support for ENUM (RFC 2916), 
which describes a means of resolving E.164 numbers to Internet resources (such as 
SIP URIs or IP addresses), allows SIP servers and clients to send and receive 
telephone numbers in place of SIP URIs in messages, and route them in a sensible 
fashion. Thus, examples of acceptable SIP URLs include: 
sip:j\doe@big.com 

slp:j.doe:secret@big.com;transport==tcp 
sip:j.doe@big.com?subject=project 

sip:+1.212-555-1212:1234@gateway.com;user=:phone 

sip: 121 2@gateway.com 

slp:alice@10.1.2.3 

sip:alice@registrar.com;method=REGISTER 

Figure 9: Examples of valid SIP URLs 

When an e.164 number Is used, the IMS will attempt to translate the address to a SIP 
URL, for sensible routing. In the case that a SIP URL is not applicable, the IMS will 
forward the sesston establishment to the PSTN/ISDN networtc for continued routing. 
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3.6 Operation and Maintenance 

Ericssons operation and maintenance solution includes element management and 
subnetwork management functionality. Standardised IRP interfaces supported. 

3.6.1 Element Management HSS. CSCF (U S>. PA. MGCF. MRFC and. BGCF 

Element Management functionality is provided from a Toolbox which can be launched 
from any standard web-browser. The following functionality is provided in the O&M 
Toolbox: 

• Performance management. Dashboard application allows the user to select any 
available performance management counters for display in a GUI. 

• Configuration Management LDAP Browser for debugging, configuration 
management, system maintenance, and provisioning activities. Signalling stacli 
GUI. 

• Fault Management. 

7^ • Alann and Notification web viewer. 

^3 • Security GUI is provided for user, password and pennisslons management 

!.n • Product inventory. Files containing hardware and software Information that can be 

«^ accessed from an external management system. 

3.6.2 Element Management MGW. SG fintf ^f^fp 

« 

i;g 

f y The Element Management function is built on a thin client application using CORBA 
Q technology. It can ain from a standard web browser on any computer, either locally or 
i;g remotely. The Bement Manager supports the following applications: 
a • Fault Management Alarm log and alami list are accessible from the element 
f U manager. Documented operational procedures are connected to each alarm, and 
are available on-line. 

• Software Management. Software installation and upgrade can be perfonned 
manually via the element manager 

• Equipment Management Hardware product inventory Information Is provided in 
the element manager (XML fiie bn^wsing) 

• Configuration Management GUI and scripting interfeces are available for 
configuring and controlling physical interfaces, link protocols and devices 

• Perfonnance Management Performance Data IRP is provided to allow 
performance managers to control and read the counters. No support is provided in 
the element manager for control or reading of performance counters on the node 
level. 

3.6.3 Subnetwork mgnggement 

The CN-OSS subnetwork manager is available to manage the IP multimedia nodes, in 
addition to the taslcs it perfonms in managing the traditional core network nodes 
already deployed. 

Each of the applications in the CN-OSS solution are designed to: 

• Provide centralised management for core network and IP Multimedia nodes 
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• Reduce time required to perform management tasks 

• Reduce the time, and cost required, to build user competence 

• Minimise the time that parts of the core network are not in sen/ice 

The diagram below shows CN-OSS and the nodes that It manages. 
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The CN-OSS subnetwork manager provides the following functionality: 

• Software managenient / upgrade. 

• Fault Management, Including: 

• Fault Management Mediation 

• Fault Management Presentation 

• Fault Manager Dcpert (FMX) (rule-based expert system) 

• Perfomiance Management 

• Configuration Management 

• Job Manager. 

• The Job Manager in CN-OSS provides the capability to define work activities 
that can be executed for nodes and node types managed by CN-OSS. 

3. 7 Transport of applications flows 

When using the WCDMA technology to access the SIP based IP multimedia system, 
the SIP signalling and the media streams must be transported over the Universal 
Terrestrial Radio Access Network (UTRAN) and Packet Switched domain {PS 
domain). Efficient usage of air interface resource is enabled with careful choice of the 
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configuration used to transport the IMS bearers, induding the SIP signalling and 
media. 



IP, RTP HeaiSBT 




□ Figure 10 Transport of Application flows - Voice Only 

\^ The terminal chooses the means by which the Application flows should be transported 
S over the UMTS network. This is dependant upon the application, the availability of 
li* radio bearers, charging considerations. Figure 10 shows a voice communication 
m using the SIP based IP multimedia system. The SIP/SDP signalling, tfie AMR (RTP) 
media and the RTCP signalling has their own PDP contexts (and hence Radio access 
bearers). The PDP context for SIP/SDP signalling is always active to enable the 
temiinai to receive IMS sessions, but during Idle periods the RAB can be deactivated. 
The terminal selects the configuration of the access network required to supports the 
communication media's negotiated through the SIP signalling. When establishi ng the 
required configuration, the tenninal provides the required Traffic flow template (TFT) 
information to the GGSN. instructing the GGSN to place the correct flows in the 
selected PDP contexts. The tenninal must hence know how to map the signalling and 
media flow to PDP contexts. 
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Figure 1 1 Transport of Application flows - Voice and Video 

Figure 1 1 illustrates the scenario where video and voice communication occurs using 
the IMS. In tills example application scenario, the Video component (H.263) is 
transported on a separate PDP context and RAB. The details for the support of this 
scenario require further investigation. 

3.8 Charging 

3.8,1 C?engra| 

The way charging data is collected for the SIP based IP Multimedia services differ 
significantly from traditional telecom networks. The main reason behind this is that the 
signalling and the bearer nomnally do not follow the same path. Therefore, the basic 
principle is to handle charging for signalling and the bearer separately. 

The following infonnation can be input into the charging system: 

• Transport information: Charging information of the used bearer resources is 
obtained from the PS domain. 

• IP Multimedia session based information: Charging infomiation provided by the 
SIP based IP multimedia system is collected from the SIP proxies. This includes 
also charging for SIP messages if they have added value (for instance, instant 
messages that can be sent in a SIP message) 

• Content based information: This means the charging for the provisioning of 
infonnation, like sports highlights, games. The charging information for content is 
delivered from the Sen^ice Networic. 

The following charging models can be supported: 

• The calling party may incur charges entirely for both the IMS level charging and 
the transport (GPRS) level charging at calling and called party sides. Initially. 
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operators may require inter-operator agreements to enable this until the standards 
are stable. 

• The calling party incurs transport level charging on the calling part/s side only and 
the entire charges related to the (MS session level. In this charging model, the 
called party incurs the transport level charging associated with that session of the 
called party's side. The called party pays for Its own transport level resources. 

Each media component within an IMS session can be charged separately. If the 
called party request additional media components with regards to the initial request 
from the calling party, then the called party can be charged for these additional 
components. 

In the case of roaming, the called party incurs charges up to the home networic of the 
called party at the transport level. The latter incurs additional charges due to roaming 
from the home network to the visited network. 

Q The transport and the session charging will occur Independently if no binding 

l,U mechanism exists to correlate the charging infonnation. The charging con-elation is 

in under investigation in 3GPP but a standardised solution has not yet been defined. It 

«p will be supported when defined. When support temiinals using IPv4 to access the SIP 

j;g based multimedia network, the binding will not occur. 

)^ 3.8.2 PrBDaidff^QStPaid Convergent 

Q The dominating charging trend today is the rapkf growth in PrePaid subscribers. The 

f y next foreseeable step is that ail network sen/ices will be rated in real-time, which 

Q would mean a convergence of PrePaid and classic PostPaid. It would also mean that 

i;g real-time rating becomes a core functfon in the network rather than a service. The Pre- 

ta Paid/PostPaid convergence allows the same charging, administration and rating 

ry systems to be used for all PSTN, GSM, UMTS and IP subscnl)ers. 

3.8.3 Online Charging 

Online charging is commonly used today for GSM prepaid subscribers. This is also 
expected to be the case for prepaid IP Multimedia users. Addrtfonally, with the 
convergence of prepaid and postpaid, all users will have the ability to have online cost 
control. The exact mechanism for the online charging is stiil being standardised. 

3.9n4 Offline Qhqrging 

Charging infomiation can be collected in different levels offline, producing CDRs that 
can foe transported to the diarging system. 

3.9 Interworking 

- Input from LMF (Janne Soutola) on Friday 

4 Product view 



4.1 Ericsson products 
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Considering the complex functional IMS architecture, it is essential to do a smart 
mapping between logical functions and actual products. A scalable and flexible IMS 
solution should be used. 

It is also reasonable to believe that the first commercial deployments of IMS products 
\m\\ start on a smaller scale. It is therefore essential to have cost-efficient entry-level 
solutions that will still provide enough capacity to handle the initial IMS traffic. As the 
market evolves, more flexible and powerful configurations will be required. 

The Ericsson IMS product line will fulfil both the scalability and the flexibility 
requirements by Implementing the IMS functfons In an Integrated, yet modular, way by 
using the following guidelines: 



- provide scalability from entry-level (Integrated) to high-end (distributed) 
configurations 

- flexible software architecture (e.g. separate S-CSCF, l-CSCF and P-CSCF 
Q modules) allowing both combined and distributed solutions, where and 

U when needed 

m - implement servers on TSP 

«P - implement gateway and media functions on CPP for media and signalling 

gateways and media mixing 

<i3 



W 4.1.1 TSP 

O ^ platform for server and control network elements and Is deployed in TDMA 

|Jy and CDMA networks. TSP is a suitable platfonn for nodes that require high availabilrty 
i; j and scalability such as the IMS nodes. 

Q The architecture of TSP consists of functional units embedded In a framework of open 
I'U Interfaces. This allows the same software to be run on different hardware. The TSP 
uses primarily commercial components. Ericsson develops the most essential 
components for adding value In tenms of robustness and scalability. 

Linux is supported in the TSP processor cluster. Fuhcttons for scalability and 
avaliabiltty are then added. 

4,t2 CPP 

CPP is a generic platform for small to medium scale telecom applications. It has a 
robust distributed real-time telecom control system and low-cost ATM, TDM and IP 
transport 



CPP is used today in Ericsson products (e.g. RNC. BTS, MOW) In the first 3G 
systems rolled out around the worid. 
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Figure 12 Mapping of IMS functions to products 

Ericsson IP-works develops DNS and DHCP products adapted to mobile networks. 
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Figure 13 IMS commercial system configuration 

Rgure 13 shows an example of a configuration able to handle higher volumes of IMS 
traffic. We can distinguish primary, secondary and access sites. The secondary sites 
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coutd host P-CSCF functionality to handle the interface to the UE and fonvard the 
sessions to the appropriate primary sites. The primary sites host the functions 
providing the actual session control and services. The access site handles the 
interface to extemal GSTNs. 

Figure 13 obviously shows only one possible scenario. Using the flexibility of our iiVlS 
product offering, many other configurations can be created, suited to specific network 
deployment scenarios. 

4.2 Ericsson Joint Ventures 

The GGSN J20 is a earner-grade and router-based GGSN. It is a joint venture 
between Ericsson and Juniper Networi^s. This GGSN functionality is built on the 
platform of the Juniper Networks M20 Internet backbone router. 

4.3 Ericsson partner products 

For the IP infrastructure in the site Ericsson use products from our partners Netscreen 
for Firewalls, and Extreme for LAN switches. These products are well suited for 
earner class networics with high availability architecture and hardware supported 
filtering and fbnvarding. The partnership includes Wentilying and implementing specifte 
mobile network requirements. 

The partnership with Juniper Networics mentioned eariier for GGSN aims also to 
provWe earner dass router family with enhancement for the mobile core networie 
Edge routers are nomially based on the AXI520 series (equal to Juniper M20, M40 
series). A new GGSN product J20 has been developed based on the Juniper router 
platfonn. For the cxsre routers in the backbone either the AXI520 or AXI580 (equal to 
Juniper M20, M40, M160) can be used. The partnership between Ericsson and 
juniper combines unique competence about mobile systems with unique competence 
about how to buOd earner class routers. 

Products from other vendors might be used as well If they support the same functions 
as the products from the partners. 

5 Migration 

5.1 Overview 

The path to supporting a conversational SIP based IP multimedia system are: 

• Demonstration System 

The SIP based (P multimedia system demonstrating the SIP capabilities and is 
available on the Ericsson premisis. 

• SIP based IP multimedia Trial System 

AvaKabte on the operators premises, and is available for IPv4. 

• Non conversational SIP based IP multimedia subsystem 

A commercial system support best effort multimedia over the PS domain and voice 
over the CS domain. 
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• Conversational SIP based IP multimedia sub^stem 

A commercial system supporting conversational multimedia over the PS domain. 

5.2 Trial system 

The trial site will provide full IMS functionality, including support for e.g. video- 
conferendng and intero/orldng with GSTNs. it will also provide a local service 
execution environment on the CSCF. Figure 15 below shows an example IMS product 
configuration for trial systems: 




Id 



Rgurs 14 IMS trial systtm conflgunrtlQn 

ru 

j;3 5.3 Non-conversational SIP based IP Multimedia system 

A ^ep towards a reaWme conversatlonsi SIP based IP multimedia system is shown 
in Figure 15. In this migration step, the IMS part of the networic is an IMS compliant 
subset of the network. As the terminals will be dual mode, supporting the real-time 
voice to be transported over the CS domain. 
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..p Rgure 15 Migration architecture 

The main features of the proposed migration network are: 

• Compliant to IMS. A subset which allows for the addition of the PCF. 

;U MRFCMRFP and intenrt/orking when increasing the capabilities of the IMS network 

j'y • Support for presence and instant messaging 

i;3 • Support for services supported with the bearers which can be created with the 

iQ deployed radio access network 

O # Simplified charging model: Each party pays their own transport usage, without 

! y conrelatton between session and transport 
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